# Вступление
Привет, меня зовут Сухушин Александр, я frontend-разработчик в компании Userstory.
Предлагаю вашему вниманию доклад на тему: "Дизайн-система. Как подружить дизайн и front-end"

# Введение

## Актуализация
Несмотря на то, что место front-end - на переднем крае, на самом деле он находится посередине. И эффективность front-end разработчика сильно зависит от того, на сколько хорошо налажены коммуникации со смежными направлениями.

Сейчас можно найти целую массу статей в сети-интернет, рассказывающих о проблемах коммуникации дизайнеров и верстальщиков. На мой взгляд общая причина этих проблем, в том, что при подготовке макетов, фактически рисуется "картинка", из которой верстальщик пытается понять, каким образом должна функционировать вся страница и отдельные её компоненты. Более правильным, на мой взгляд, здесь будет: сначала описать правила оформления, а уже на их основе потом создавать макеты.

# Основная часть

## Обзор
Набор таких правил называется "Дизайн-система". Такие новые инструменты как, Sketch, Adobe XD, Figma и прочие призваны помочь перейти на подход дизайн-систем. К сожалению, на данный момент - очень мало информации о том, как проектировать такие системы, настолько мало, что это единственное более-менее адекватное определение, которое мне удалось найти: "Дизайн-система — это постоянно эволюционирующий свод правил, который определяет порядок создания продукта." (https://habrahabr.ru/company/everydaytools/blog/324774/). А использование новых инструментов без соответствующих навыков - крайне не эффективно.

## Решение
Поэтому я попытался сформировать правила описания такой системы, которые были бы удобны мне, как front-end разработчику.

### Слои
Основная идея заключается разделении описания на "слои", для большего удобства будем использовать возможности CSS-препроцессоров, а именно переменные и примеси (миксины).

### Слой 0 - "Палитра"
Начать описание, следует наиболее общих вещей, таких как, цветовые схемы, оформление шрифтов, метрики и т.д. При этом каждому значению задаётся своё название - "псевдоним". Главная задача на этом этапе - абстрагироваться от конкретных значений. Заметьте, здесь заданы две колонки текста с одинаковыми псевдонимами, но разными размерами, таким образом, уже на этом этапе мы можем предусмотреть различное оформление текста для различных устройств: мобильные устройства, Большие экраны. Уже на этом этапе, с помощью переменных, можно переносить эту информацию в CSS.

### Слой 1 - "Базовые элементы"
Теперь, когда у нас есть палитра, мы можем, на её основе, описать базовые элементы, такие как заголовки, списки, ссылки и т.д. Также сюда можно включить некоторые нестандартные элементы, которые в вашем дизайне будут являться базовыми, например, подписи к изображениям, цитаты, сноски и прочие. Также, как и в предыдущем этапе, каждому новому элементу присваивается свой псевдоним и может быть перенесено в CSS с помощью переменных и примесей.

### Слой 2 - "Составные элементы"
Аналогичным образом, при необходимости, можно создавать всё более и более сложные элементы.

### Правила
Таким образом можно выделить некоторые правила, которым нужно следовать при составлении дизайн-систем:
 - Описание должно идти сверху вниз, то есть, сначала описываются более общие правила, затем более частные;
 - Описание разбивается на слои, для каждой сущности слоя определяется свой псевдоним;
 - Описание сущности на одном из слоёв должно как можно более полно использовать сущности предыдущих слоёв.

# Заключение

## Примеры
В нашей компании уже есть опыт частичного внедрения подобного подхода:
(Телебриз)

## Преимущества
Подводя итоги, я бы хотел выделить следующие преимущества, которые даёт использование подобной системы:
 - Уменьшение накладных расходов при передаче дизайна, как следствие ускорение вёрстки за счёт использования псевдонимов; 
 - Проще поддерживать и контролировать энтропию в стилях (невнимательность, неправильный цветовой профиль, ...); 
 - Параллельное описание дизайна и вёрстка; 
 - Повторное использование как целых блоков, так и отдельных элементов оформления.